home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Experimental BBS Explossion 3
/
Experimental BBS Explossion III.iso
/
compress
/
acmp_300.zip
/
ACMP-300.TXT
next >
Wrap
Text File
|
1993-06-09
|
117KB
|
2,370 lines
ARCHIVER COMPARISON -- Version 3.00
June 9, 1993
by Dean W. Cooper
What is this?
-------------
This file presents the results of tests that I ran on a number
of archivers including the latest versions of PKZIP, ARJ, LHA, and
others. Tests were run on 12 different sets of files of various
types. The program DCCMP (included in this distribution), is the
program I wrote to automatically run the tests. It can be used to
run tests on your own data.
This file and the program DCCMP may be freely used and distributed,
but please distribute all files together.
Who am I?
---------
Years ago when PKARC was the main archiver, I wrote the DWC
archiver which was equal in speed and compression size to it.
Although I haven't written a new archiver lately, I am still curious
as to how the new archivers are doing. So, from time to time I run
some tests.
Questions? Comments? Leave a message for me at:
(414) 789-4210 Exec-PC
(516) 536-8723 Sound-of-Music BBS (Home of SMARTNET)
(602) 326-2403 (voice)
Or write to:
Dean W. Cooper
3078 N. Palo Verde
Tucson, AZ 85716
What is contained in this distribution?
---------------------------------------
The following is a list of files I have included in this distribution
and what they are:
ACMP-300.TXT -- Archiver comparison, version 3.00 (this file).
Contains the results of the tests in raw form and
in summarized tabular format. Also includes general
information, a list of what archivers were tested,
and a list of what each test set was composed of.
DCCMP.EXE -- My comparer program. This is what I used to generate
the raw data. Simply run "DCCMP" to get complete
usage information.
ARCHIVE.CMP -- The DCCMP format batch file that tells my program
what archivers to run, and how to run them.
ACMP.BAT -- The DOS batch file I used to run my DCCMP program
with.
What was tested?
----------------
I tested 12 separate sets of files. The test sets were compressed
and extracted three times each in order to make sure timings were
accurate.
The following archivers and options were tested:
PKZIP 2.04g -a -ex -- Phil Katz's PKZIP (max compression)
PKZIP 2.04g -a -en -- .. PKZIP (normal compression)
PKZIP 2.04g -a -ef -- .. PKZIP
PKZIP 2.04g -a -es -- .. PKZIP (fastest)
ARJ 2.39f a -m1 -- Robert Jung's ARJ (best compression)
ARJ 2.39f a -m3 -- Robert Jung's ARJ
ARJ 2.39f a -m4 -- Robert Jung's ARJ (fastest)
ARJ 2.39f a -jm -- Robert Jung's ARJ (maximum compression)
ARJ 2.39f a -jm1 -- Robert Jung's ARJ (faster max compression)
SQZ 2.08.3e a -q0 -- Swedish archiver (best compression)
SQZ 2.08.3e a -q3 -- Swedish archiver
SQZ 2.08.3e a -q6 -- Swedish archiver
SQZ 2.08.3e a -q9 -- Swedish archiver
SQZ 2.08.3e a -m1 -- Swedish archiver (fastest)
LHA 2.52 a -n -- Yoshi's latest version of LHARC
HYPER 2.5 -a -- German archiver
ZIP 1.9 -1 -- Freeware ZIP compatible (fastest)
ZIP 1.9 -3 -- Freeware ZIP compatible
ZIP 1.9 -6 -- Freeware ZIP compatible
ZIP 1.9 -9 -- Freeware ZIP compatible (best compression)
HAP 3.00 a -- Archiver from The Netherlands
Note that most of the archivers are tested with multiple options. The
options offer a range of trade-offs between compression size and compression
speed. Indeed, I did not attempt to test ALL possible options but just a
sampling to give a good idea of the possible range for each archiver.
The test system?
----------------
The tests were run on a 386 PC compatible with Peter Norton SI
ratings of:
Computing Index: 28.8
Disk Index: 3.0
o The computer was setup as follows:
- DOS 5.0
- Windows 3.1 Smartdrv, 2 Meg, with write cache On.
- Windows 3.1 Ramdrive, 1.2 Meg
- Windows 3.1 EMM386, 3.5 Meg XMS memory
- 517K conventional memory available to archivers
- TMP & TEMP environment variables pointing to ramdrive
o My computer has one 302 Meg hard disk partitioned into 6 logical
drives. All tests were run on the 42 Meg partition F:.
o All tests were run three times to get accurate timings.
o Each set of files was put in a separate directory on drive F: (in the
directories f:\test1, f:\test2, etc).
o The files were extracted to the empty directory f:\temp.
o In the following, the line "DCCMP ..." tells the exact arguments that
were passed to the comparer program DCCMP.
What to look for...
-------------------
The wide range of compression options makes it difficult to rate which
archiver is the best since the fastest options usually offer very poor
compression and the maximum compression options are usually very slow
(and often with little actual savings). Thus, we need to look for the
following:
Category 1: Great compression size, ok speed.
Look for an archiver that gets great compression size, but without
making you wait forever. Waiting a little longer for a significant
improvement is OK, but it is not OK to wait a lot longer for only
a few more bytes saved.
Category 2: Great compression speed, ok size.
Look for an archiver that is very fast without sacrificing a lot in
compression size.
Category 3: Absolute best compression size, speed doesn't matter.
Just look for the archiver that compresses the smallest and ignore
how long it took to do it, or how long it will take to extract.
Category 4: Great extraction speed, decent compression.
Look for an archiver that can extract fast, but only if its
compression was good enough to make de-compression meaningful.
On each of the 12 test sets, I will rate the archivers and select a
first, second, and third place winner for each of the above categories.
Then, at the end, I will list the cumulative results. However, since
archivers vary depending on the type of data compressed, look for the
best archiver on the type of data you use the most.
Please note that the ratings are a bit subjective, so if you don't
like or trust my judgments, then take a good look at the raw numbers
yourself.
Of course there are other factors to consider in archivers like
features, support, popularity, etc., but this particular comparison does
not specifically measure those items.
The results...
--------------
---- TEST SET 1 -----------------------------------------------------
Files from the Apogee game Major Stryker Ver 1.3. The two large files
contain a lot of graphical data.
catalog.exe 27,019 bytes
file_id.diz 347 bytes
license.doc 4,490 bytes
major.exe 84,250 bytes
order.frm 2,855 bytes
volume1a.ms1 890,069 bytes
volume1b.ms1 989,752 bytes
-------
1,998,782 total bytes in 7 files
DCCMP run as: "DCCMP -3 -ts -otest1.rsl archive test1 f:\test1\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:54:10
Total time elapsed: 2:42:31
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 440 000:24.2 653215 1.00
ARJ 2.39f a -m4 642 000:35.3 657989 1.46
PKZIP 2.04g -a -ef 697 000:38.3 594145 1.58
ARJ 2.39f a -m3 805 000:44.2 601564 1.83
ZIP 1.9 -1 997 000:54.8 565174 2.26
PKZIP 2.04g -a -en 1027 000:56.4 564845 2.33
ZIP 1.9 -3 1126 001: 1.9 548431 2.56
SQZ 1.08.3e a -q9 1261 001: 9.3 582876 2.87
HYPER 2.5 -a 1352 001:14.3 630809 3.07
SQZ 1.08.3e a -q6 1501 001:22.5 550138 3.41
ZIP 1.9 -6 1561 001:25.8 538085 3.55
LHA 2.52 a -n 1637 001:29.9 582538 3.72
ARJ 2.39f a -m1 1751 001:36.2 574631 3.98
SQZ 1.08.3e a -m1 1851 001:41.7 548872 4.20
PKZIP 2.04g -a -ex 1894 001:44.1 536813 4.30
ARJ 2.39f a -jm1 2158 001:58.6 573139 4.90
SQZ 1.08.3e a -q3 2543 002:19.7 542306 5.78
ARJ 2.39f a -jm 4363 003:59.7 571216 9.91
ZIP 1.9 -9 4917 004:30.2 534439 11.17
SQZ 1.08.3e a -q0 6337 005:48.2 540159 14.39
HAP3 3.00 a 6432 005:53.4 629815 14.61
>> Notice how there are several groups of performance here. They are:
1) 650K size: PKZIP:es, ARJ:m4
... Poor compression, but very fast. PKZIP:es is the pick here
because it is significantly faster and even has slightly better
compression size than ARJ:m4.
2) 600K size: PKZIP:ef, ARJ:m3
... Better compression, but slower. Notice how PKZIP:ef gets the
better level of compression while being almost as fast as
ARJ:m4 from level 1.
3) 560K size: PKZIP:en, ZIP:1
... Good compression, slower still. These two are about the same
at this level. Remember, I didn't try testing ARJ:m2.
4) 548K size: ZIP:3
... Inbetween levels. Here PKZIP does not offer the flexibility
of ZIP to choose such a variety of levels. Indeed, I did not
even test all of ZIP's 9 levels.
5) 537K size: PKZIP:ex, ZIP:6
... Great compression, even slower. This looks like ZIP:7 (level
not tested) would have been almost equal to PKZIP:ex.
6) 534K size: ZIP:9
... Best compression, but very slow. To get 2000 more bytes
compressed, we had to wait almost 3 minutes longer. But at
least ZIP:9 offered the option.
>> Notice how ARJ falls out of the competition after ARJ:m3. ARJ:m1 takes
almost twice as long as PKZIP:en to get poorer compression size. ARJ:jm1
and ARJ:jm take even longer, but still don't compress better than PKZIP:en.
>> SQZ does get good compression, but always lags significantly behind PKZIP
and ZIP in speed for the same level of compression. And, although SQZ:q9
takes 4 minutes longer, it still can't manage to beat PKZIP:ex in
compression size.
>> LHA's one level of compression is easily out done by both PKZIP and ZIP
in both speed and size.
>> HYPER is slow and compresses poorly.
>> HAP is Very slow and compresses poorly.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
ZIP 1.9 -9 4917 004:30.2 534439 1.00
PKZIP 2.04g -a -ex 1894 001:44.1 536813 1.00
ZIP 1.9 -6 1561 001:25.8 538085 1.01
SQZ 1.08.3e a -q0 6337 005:48.2 540159 1.01
SQZ 1.08.3e a -q3 2543 002:19.7 542306 1.01
ZIP 1.9 -3 1126 001: 1.9 548431 1.03
SQZ 1.08.3e a -m1 1851 001:41.7 548872 1.03
SQZ 1.08.3e a -q6 1501 001:22.5 550138 1.03
PKZIP 2.04g -a -en 1027 000:56.4 564845 1.06
ZIP 1.9 -1 997 000:54.8 565174 1.06
ARJ 2.39f a -jm 4363 003:59.7 571216 1.07
ARJ 2.39f a -jm1 2158 001:58.6 573139 1.07
ARJ 2.39f a -m1 1751 001:36.2 574631 1.08
LHA 2.52 a -n 1637 001:29.9 582538 1.09
SQZ 1.08.3e a -q9 1261 001: 9.3 582876 1.09
PKZIP 2.04g -a -ef 697 000:38.3 594145 1.11
ARJ 2.39f a -m3 805 000:44.2 601564 1.13
HAP3 3.00 a 6432 005:53.4 629815 1.18
HYPER 2.5 -a 1352 001:14.3 630809 1.18
PKZIP 2.04g -a -es 440 000:24.2 653215 1.22
ARJ 2.39f a -m4 642 000:35.3 657989 1.23
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-ex) 183 000:10.1 1.00
PKUNZIP 2.04g -e (-en) 194 000:10.7 1.06
PKUNZIP 2.04g -e (-ef) 208 000:11.4 1.13
PKUNZIP 2.04g -e (-es) 219 000:12.0 1.20
LHA 2.52 e -n 269 000:14.8 1.47
ARJ 2.39f e (-jm1) 285 000:15.7 1.55
ARJ 2.39f e (-jm) 292 000:16.0 1.60
ARJ 2.39f e (-m3) 296 000:16.3 1.62
ARJ 2.39f e (-m1) 297 000:16.3 1.62
ARJ 2.39f e (-m4) 324 000:17.8 1.77
SQZ 1.08.3e e (-q0) 339 000:18.6 1.85
SQZ 1.08.3e e (-q3) 350 000:19.2 1.91
SQZ 1.08.3e e (-m1) 357 000:19.6 1.95
SQZ 1.08.3e e (-q6) 360 000:19.8 1.96
SQZ 1.08.3e e (-q9) 380 000:20.9 2.07
UNZIP 5.00 -j (-9) 590 000:32.4 3.22
UNZIP 5.00 -j (-6) 610 000:33.5 3.33
UNZIP 5.00 -j (-1) 631 000:34.7 3.45
UNZIP 5.00 -j (-3) 641 000:35.2 3.50
HYPER 2.5 -x 663 000:36.4 3.62
PAH3 3.00 e 6280 005:45.1 34.26
>> The quality of extraction code is clearly shown here with PKUNZIP
being the best. LHA, ARJ, and SQZ follow up with respectable
performance.
>> But while ZIP might have been on par with PKZIP in compression, it
clearly falls behind in de-compression being over 3 times slower.
>> And PAH is extremely slow. Look at it! Almost 6 minutes compared
to PKUNZIP's 10 seconds! This either shows very poor code or a
significantly different algorithm than anyone else. But I don't
think it's poor code. It would be hard to be THAT poor even if one
tried. Moreover, the size of the HAP and PAH executables seem to
indicate it was written in assembler. The question is then, what
algorithm is it using? Perhaps it uses LZ sliding window combined
with arithmetic coding?
>> Also notice that PAH's de-compression takes about the same amount of
time as HAP's compression, while everybody else was considerably faster
at de-compression the compression.
╓──────────────────╖
║ Winners Set 1 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║
║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║
║ Category 3 (abs size): ZIP best, then PKZIP, then SQZ ║
║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 2 -----------------------------------------------------
The last publicly available source code to DWC versions A5.12 & A4.95.
These files are from the official source code distribution archive
A495-512.DWC
dwc 768 bytes
dwc.c 163,840 bytes
dwcmisc.asm 4,096 bytes
dwcmisc.c 2,816 bytes
dwcmod.c 10,752 bytes
dwcsfx.c 41,472 bytes
dwcsize.asm 15,616 bytes
dwcsize.c 7,680 bytes
dwcspeed.asm 11,520 bytes
dwcspeed.c 6,400 bytes
dwcunc.asm 16,000 bytes
dwcunc.c 8,320 bytes
dwcv.c 17,536 bytes
dwcwild.c 8,192 bytes
header 256 bytes
makesfx.c 14,208 bytes
source.doc 33,920 bytes
-------
363,392 total bytes in 17 files
DCCMP run as: "DCCMP -3 -ts -otest2.rsl archive test2 f:\test2\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:07:50
Total time elapsed: 0:23:32
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 58 000: 3.2 115708 1.00
PKZIP 2.04g -a -ef 93 000: 5.1 99284 1.59
PKZIP 2.04g -a -en 121 000: 6.6 95573 2.08
ARJ 2.39f a -m4 122 000: 6.7 113165 2.10
ARJ 2.39f a -m3 143 000: 7.9 101371 2.46
ZIP 1.9 -1 158 000: 8.7 99725 2.72
ZIP 1.9 -3 178 000: 9.8 97075 3.05
PKZIP 2.04g -a -ex 187 000:10.3 94376 3.21
SQZ 1.08.3e a -q9 195 000:10.7 101497 3.35
HYPER 2.5 -a 211 000:11.6 103782 3.62
ZIP 1.9 -6 218 000:12.0 95211 3.74
ARJ 2.39f a -m1 253 000:13.9 95823 4.34
SQZ 1.08.3e a -q6 260 000:14.3 95781 4.47
ARJ 2.39f a -jm1 265 000:14.6 95631 4.55
LHA 2.52 a -n 307 000:16.9 99219 5.27
SQZ 1.08.3e a -m1 332 000:18.2 95305 5.69
SQZ 1.08.3e a -q3 386 000:21.2 94086 6.63
ARJ 2.39f a -jm 423 000:23.2 95216 7.25
ZIP 1.9 -9 510 000:28.0 94478 8.75
SQZ 1.08.3e a -q0 767 000:42.1 93601 13.16
HAP3 3.00 a 805 000:44.2 84126 13.80
>> With this test set (all C source code and English documentation) we have
a different mix as compared to the first test set.
>> Notice that while PKZIP has only four levels, three of the levels are
faster than any other archiver (albeit, the third level just barely).
>> While PKZIP:es does compress the poorest, it does compress twice as fast
as ARJ:m4 and only loses 2500 bytes in size.
>> Notice that all four levels of PKZIP are the quickest to reach the
respective compression sizes that they achieve. For example, ZIP:6 takes
twice as long as PKZIP:en to reach 95000 bytes in size. And SQZ:q3 takes
twice as long as PKZIP:ex to reach 94000 bytes.
>> If you're willing to wait 4 times as long as PKZIP:ex, then SQZ:q0 will
squeeze out 800 bytes more for you, but who cares?!
>> If you forget about PKZIP for a moment, you'll see that ARJ and ZIP are
about equal in this test set, with SQZ coming in close behind.
>> But look at HAP's compression. While everybody else is taking more and
more time to simply approach 93000 bytes, HAP simply skips by them and
compresses to 84000 bytes. A significant improvement. Obviously, HAP
uses a different algorithm. It's a slow algorithm, but for some types
of data, it compresses significantly better than any other archiver.
>> Forget HYPER and LHA (at least in this test case), they are easily
outdone by the other archivers.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 805 000:44.2 84126 1.00
SQZ 1.08.3e a -q0 767 000:42.1 93601 1.11
SQZ 1.08.3e a -q3 386 000:21.2 94086 1.12
PKZIP 2.04g -a -ex 187 000:10.3 94376 1.12
ZIP 1.9 -9 510 000:28.0 94478 1.12
ZIP 1.9 -6 218 000:12.0 95211 1.13
ARJ 2.39f a -jm 423 000:23.2 95216 1.13
SQZ 1.08.3e a -m1 332 000:18.2 95305 1.13
PKZIP 2.04g -a -en 121 000: 6.6 95573 1.14
ARJ 2.39f a -jm1 265 000:14.6 95631 1.14
SQZ 1.08.3e a -q6 260 000:14.3 95781 1.14
ARJ 2.39f a -m1 253 000:13.9 95823 1.14
ZIP 1.9 -3 178 000: 9.8 97075 1.15
LHA 2.52 a -n 307 000:16.9 99219 1.18
PKZIP 2.04g -a -ef 93 000: 5.1 99284 1.18
ZIP 1.9 -1 158 000: 8.7 99725 1.19
ARJ 2.39f a -m3 143 000: 7.9 101371 1.20
SQZ 1.08.3e a -q9 195 000:10.7 101497 1.21
HYPER 2.5 -a 211 000:11.6 103782 1.23
ARJ 2.39f a -m4 122 000: 6.7 113165 1.35
PKZIP 2.04g -a -es 58 000: 3.2 115708 1.38
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-ef) 34 000: 1.9 1.00
PKUNZIP 2.04g -e (-en) 34 000: 1.9 1.00
PKUNZIP 2.04g -e (-ex) 36 000: 2.0 1.07
PKUNZIP 2.04g -e (-es) 48 000: 2.6 1.41
LHA 2.52 e -n 57 000: 3.1 1.69
SQZ 1.08.3e e (-m1) 67 000: 3.7 1.99
SQZ 1.08.3e e (-q0) 68 000: 3.7 2.01
SQZ 1.08.3e e (-q3) 68 000: 3.7 2.01
SQZ 1.08.3e e (-q6) 70 000: 3.8 2.07
SQZ 1.08.3e e (-q9) 74 000: 4.1 2.18
ARJ 2.39f e (-jm) 76 000: 4.2 2.25
ARJ 2.39f e (-jm1) 77 000: 4.2 2.26
ARJ 2.39f e (-m1) 79 000: 4.3 2.32
ARJ 2.39f e (-m3) 81 000: 4.5 2.39
ARJ 2.39f e (-m4) 87 000: 4.8 2.57
UNZIP 5.00 -j (-9) 115 000: 6.3 3.40
UNZIP 5.00 -j (-3) 125 000: 6.9 3.68
UNZIP 5.00 -j (-6) 126 000: 6.9 3.72
HYPER 2.5 -x 142 000: 7.8 4.19
UNZIP 5.00 -j (-1) 148 000: 8.1 4.36
PAH3 3.00 e 884 000:48.6 26.01
>> These results are about the same as the first test set except this time
SQZ extracts a little faster than ARJ.
>> Again, PAH takes a very long time to de-compress and actually takes longer
then HAP took to compress.
╓──────────────────╖
║ Winners Set 2 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then SQZ, then ZIP ║
║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║
║ Category 3 (abs size): HAP best, then SQZ, then PKZIP ║
║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 3 -----------------------------------------------------
A 16 bit-per-pixel true color digitized image of the grand canyon.
canyon.img 359,934 bytes
DCCMP run as: "DCCMP -3 -ts -otest3.rsl archive test3 f:\test3\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:09:22
Total time elapsed: 0:28:06
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 83 000: 4.6 211754 1.00
ARJ 2.39f a -m4 138 000: 7.6 215702 1.66
PKZIP 2.04g -a -ef 144 000: 7.9 193769 1.74
ARJ 2.39f a -m3 170 000: 9.3 190086 2.06
ZIP 1.9 -1 238 000:13.1 187757 2.87
HYPER 2.5 -a 284 000:15.6 190058 3.42
PKZIP 2.04g -a -en 291 000:16.0 184117 3.51
SQZ 1.08.3e a -q9 292 000:16.0 193573 3.52
ZIP 1.9 -3 321 000:17.6 186185 3.87
ARJ 2.39f a -jm1 339 000:18.6 184832 4.09
ZIP 1.9 -6 339 000:18.6 185210 4.09
ARJ 2.39f a -m1 339 000:18.6 184839 4.09
ZIP 1.9 -9 342 000:18.8 185217 4.13
ARJ 2.39f a -jm 344 000:18.9 184832 4.14
LHA 2.52 a -n 353 000:19.4 187678 4.26
PKZIP 2.04g -a -ex 374 000:20.5 183879 4.51
SQZ 1.08.3e a -q6 419 000:23.0 185262 5.05
SQZ 1.08.3e a -m1 505 000:27.7 185658 6.09
SQZ 1.08.3e a -q3 514 000:28.2 184253 6.20
SQZ 1.08.3e a -q0 527 000:29.0 184252 6.36
HAP3 3.00 a 850 000:46.7 152565 10.24
>> Again, the fastest version of PKZIP (PKZIP:es) not only is 66% faster
than the fastest version of ARJ (ARJ:m4), it also compresses better.
>> Indeed, PKZIP:ef is about the same speed as ARJ:m4, but significantly
out compresses it.
>> The first archiver to compress down to the 184000 level is PKZIP:en
with ARJ:jm1 coming in second.
>> Except for HAP which takes more than twice as long, PKZIP:ex gets the
best compression.
>> But, if you're willing to wait, HAP is the only choice you have to get
significantly better compression.
>> Again, neither HYPER nor LHA offer any reason to choose them over the
other archivers.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 850 000:46.7 152565 1.00
PKZIP 2.04g -a -ex 374 000:20.5 183879 1.21
PKZIP 2.04g -a -en 291 000:16.0 184117 1.21
SQZ 1.08.3e a -q0 527 000:29.0 184252 1.21
SQZ 1.08.3e a -q3 514 000:28.2 184253 1.21
ARJ 2.39f a -jm1 339 000:18.6 184832 1.21
ARJ 2.39f a -jm 344 000:18.9 184832 1.21
ARJ 2.39f a -m1 339 000:18.6 184839 1.21
ZIP 1.9 -6 339 000:18.6 185210 1.21
ZIP 1.9 -9 342 000:18.8 185217 1.21
SQZ 1.08.3e a -q6 419 000:23.0 185262 1.21
SQZ 1.08.3e a -m1 505 000:27.7 185658 1.22
ZIP 1.9 -3 321 000:17.6 186185 1.22
LHA 2.52 a -n 353 000:19.4 187678 1.23
ZIP 1.9 -1 238 000:13.1 187757 1.23
HYPER 2.5 -a 284 000:15.6 190058 1.25
ARJ 2.39f a -m3 170 000: 9.3 190086 1.25
SQZ 1.08.3e a -q9 292 000:16.0 193573 1.27
PKZIP 2.04g -a -ef 144 000: 7.9 193769 1.27
PKZIP 2.04g -a -es 83 000: 4.6 211754 1.39
ARJ 2.39f a -m4 138 000: 7.6 215702 1.41
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-en) 35 000: 1.9 1.00
PKUNZIP 2.04g -e (-ex) 36 000: 2.0 1.04
PKUNZIP 2.04g -e (-ef) 37 000: 2.0 1.07
PKUNZIP 2.04g -e (-es) 49 000: 2.7 1.42
LHA 2.52 e -n 68 000: 3.7 1.96
ARJ 2.39f e (-m1) 72 000: 4.0 2.07
ARJ 2.39f e (-jm) 72 000: 4.0 2.07
ARJ 2.39f e (-jm1) 72 000: 4.0 2.07
ARJ 2.39f e (-m3) 73 000: 4.0 2.10
SQZ 1.08.3e e (-q0) 85 000: 4.7 2.45
SQZ 1.08.3e e (-m1) 88 000: 4.8 2.53
SQZ 1.08.3e e (-q6) 89 000: 4.9 2.54
ARJ 2.39f e (-m4) 89 000: 4.9 2.56
SQZ 1.08.3e e (-q9) 90 000: 4.9 2.59
SQZ 1.08.3e e (-q3) 93 000: 5.1 2.66
UNZIP 5.00 -j (-6) 169 000: 9.3 4.84
UNZIP 5.00 -j (-9) 172 000: 9.5 4.92
UNZIP 5.00 -j (-3) 178 000: 9.8 5.10
UNZIP 5.00 -j (-1) 195 000:10.7 5.57
HYPER 2.5 -x 200 000:11.0 5.71
PAH3 3.00 e 1006 000:55.3 28.76
>> PKUNZIP is twice as fast extracting as ARJ, five times as fast as
UNZIP, and 28 times as fast as PAH!
>> Again, PAH takes longer to de-compress than HAP took to compress.
Perhaps PAH isn't as optimized as HAP is.
╓──────────────────╖
║ Winners Set 3 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ARJ, then ZIP ║
║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║
║ Category 3 (abs size): HAP best, then PKZIP, then SQZ ║
║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 4 -----------------------------------------------------
Files that came with the ARJ 2.30 self-extracting archive, ARJ230.EXE.
arj.doc 131,116 bytes
arj.exe 104,614 bytes
arjback.bat 137 bytes
arjrest.bat 163 bytes
arjsort.bat 3,311 bytes
arjsort.com 6,499 bytes
arjsort.doc 3,145 bytes
arjupdat.bat 145 bytes
arj_bbs.doc 3,722 bytes
credit.crd 3,251 bytes
license.doc 14,729 bytes
orderfrm.doc 5,021 bytes
readme.doc 2,440 bytes
rearj.cfg 439 bytes
rearj.doc 19,815 bytes
rearj.exe 37,762 bytes
rearjall.bat 344 bytes
register.exe 12,492 bytes
sysop.doc 1,329 bytes
technote.doc 4,764 bytes
update.doc 22,783 bytes
whatsnew.doc 10,719 bytes
why_arj.doc 5,769 bytes
-------
394,509 total bytes in 23 files
DCCMP run as: "DCCMP -3 -ts -otest4.rsl archive test4 f:\test4\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:10:27
Total time elapsed: 0:31:23
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 101 000: 5.5 205750 1.00
PKZIP 2.04g -a -ef 136 000: 7.5 191047 1.35
ARJ 2.39f a -m4 165 000: 9.1 210368 1.63
PKZIP 2.04g -a -en 184 000:10.1 185718 1.82
ARJ 2.39f a -m3 208 000:11.4 191698 2.06
ZIP 1.9 -1 238 000:13.1 189787 2.35
PKZIP 2.04g -a -ex 258 000:14.2 184524 2.55
ZIP 1.9 -3 261 000:14.3 187154 2.58
SQZ 1.08.3e a -q9 291 000:16.0 190488 2.88
ZIP 1.9 -6 295 000:16.2 185830 2.91
ARJ 2.39f a -jm 299 000:16.4 185236 2.96
ARJ 2.39f a -jm1 302 000:16.6 185235 2.98
HYPER 2.5 -a 316 000:17.4 198495 3.12
ARJ 2.39f a -m1 318 000:17.5 185308 3.14
SQZ 1.08.3e a -q6 321 000:17.6 184772 3.17
ZIP 1.9 -9 322 000:17.7 185709 3.18
LHA 2.52 a -n 334 000:18.4 190668 3.30
SQZ 1.08.3e a -m1 403 000:22.1 184424 3.98
SQZ 1.08.3e a -q3 457 000:25.1 183571 4.51
SQZ 1.08.3e a -q0 462 000:25.4 183490 4.57
HAP3 3.00 a 1439 001:19.1 176783 14.20
>> Here, two versions of PKZIP are not only faster than the fastest version
of ARJ, but also beat it significantly in size.
>> PKZIP is the first to reach the 205000 level, the first to reach the
191000 level, the first to reach the 185000 level and the first to reach
the 184000 level!
>> Notice that neither ARJ nor ZIP can beat PKZIP:ex in compression, even if
they take longer.
>> But, if you're willing to wait almost twice as long, then SQZ:q0 will save
you 1000 bytes over PKZIP:ex.
>> And, if you're willing to wait eight times longer than PKZIP:en, then HAP
will save you 9000 bytes. This is a significant savings, but eight times
longer?! And de-compression will be 36 times longer!!!
>> Forget HYPER and LHA.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 1439 001:19.1 176783 1.00
SQZ 1.08.3e a -q0 462 000:25.4 183490 1.04
SQZ 1.08.3e a -q3 457 000:25.1 183571 1.04
SQZ 1.08.3e a -m1 403 000:22.1 184424 1.04
PKZIP 2.04g -a -ex 258 000:14.2 184524 1.04
SQZ 1.08.3e a -q6 321 000:17.6 184772 1.05
ARJ 2.39f a -jm1 302 000:16.6 185235 1.05
ARJ 2.39f a -jm 299 000:16.4 185236 1.05
ARJ 2.39f a -m1 318 000:17.5 185308 1.05
ZIP 1.9 -9 322 000:17.7 185709 1.05
PKZIP 2.04g -a -en 184 000:10.1 185718 1.05
ZIP 1.9 -6 295 000:16.2 185830 1.05
ZIP 1.9 -3 261 000:14.3 187154 1.06
ZIP 1.9 -1 238 000:13.1 189787 1.07
SQZ 1.08.3e a -q9 291 000:16.0 190488 1.08
LHA 2.52 a -n 334 000:18.4 190668 1.08
PKZIP 2.04g -a -ef 136 000: 7.5 191047 1.08
ARJ 2.39f a -m3 208 000:11.4 191698 1.08
HYPER 2.5 -a 316 000:17.4 198495 1.12
PKZIP 2.04g -a -es 101 000: 5.5 205750 1.16
ARJ 2.39f a -m4 165 000: 9.1 210368 1.19
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-en) 47 000: 2.6 1.00
PKUNZIP 2.04g -e (-ex) 48 000: 2.6 1.03
PKUNZIP 2.04g -e (-ef) 65 000: 3.6 1.40
PKUNZIP 2.04g -e (-es) 77 000: 4.2 1.64
LHA 2.52 e -n 102 000: 5.6 2.17
SQZ 1.08.3e e (-m1) 104 000: 5.7 2.22
SQZ 1.08.3e e (-q6) 104 000: 5.7 2.23
SQZ 1.08.3e e (-q0) 106 000: 5.8 2.26
SQZ 1.08.3e e (-q9) 109 000: 6.0 2.32
ARJ 2.39f e (-jm) 109 000: 6.0 2.33
SQZ 1.08.3e e (-q3) 110 000: 6.0 2.35
ARJ 2.39f e (-m1) 113 000: 6.2 2.41
ARJ 2.39f e (-m3) 114 000: 6.3 2.43
ARJ 2.39f e (-jm1) 114 000: 6.3 2.43
ARJ 2.39f e (-m4) 124 000: 6.8 2.65
UNZIP 5.00 -j (-6) 188 000:10.3 4.00
UNZIP 5.00 -j (-3) 190 000:10.4 4.06
UNZIP 5.00 -j (-9) 199 000:10.9 4.25
UNZIP 5.00 -j (-1) 212 000:11.6 4.52
HYPER 2.5 -x 272 000:14.9 5.79
PAH3 3.00 e 1717 001:34.3 36.54
>> Again, PKUNZIP is twice as fast extracting as ARJ, four times faster than
UNZIP, and 36 times faster than PAH! And PAH is slower than HAP.
╓──────────────────╖
║ Winners Set 4 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ARJ, then SQZ ║
║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║
║ Category 3 (abs size): HAP best, then SQZ, then PKZIP ║
║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 5 -----------------------------------------------------
Files that came with the ZIP 2.04g self-extracting archive, PKZ204g.EXE.
addendum.doc 19,361 bytes
authveri.frm 2,330 bytes
hints.txt 14,109 bytes
license.doc 3,707 bytes
manual.doc 202,252 bytes
ombudsmn.asp 591 bytes
order.doc 3,304 bytes
pkunzip.exe 29,378 bytes
pkunzjr.com 2,750 bytes
pkzip.exe 42,166 bytes
pkzipfix.exe 7,687 bytes
readme.doc 741 bytes
sharewar.doc 573 bytes
v204g.new 10,704 bytes
whatsnew.204 2,430 bytes
zip2exe.exe 27,319 bytes
-------
369,402 total bytes in 16 files
DCCMP run as: "DCCMP -3 -ts -otest5.rsl archive test5 f:\test5\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:08:56
Total time elapsed: 0:26:50
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 85 000: 4.7 202258 1.00
PKZIP 2.04g -a -ef 139 000: 7.6 192176 1.63
ARJ 2.39f a -m4 151 000: 8.3 204075 1.77
PKZIP 2.04g -a -en 173 000: 9.5 187603 2.03
ARJ 2.39f a -m3 183 000:10.1 192558 2.14
PKZIP 2.04g -a -ex 232 000:12.7 186710 2.72
ZIP 1.9 -1 232 000:12.7 190853 2.73
ZIP 1.9 -3 233 000:12.8 188380 2.73
SQZ 1.08.3e a -q9 267 000:14.7 192453 3.13
ARJ 2.39f a -jm1 286 000:15.7 187311 3.35
ARJ 2.39f a -m1 286 000:15.7 187352 3.36
ZIP 1.9 -6 293 000:16.1 186655 3.44
HYPER 2.5 -a 302 000:16.6 197280 3.54
LHA 2.52 a -n 306 000:16.8 191378 3.59
ARJ 2.39f a -jm 309 000:17.0 187238 3.63
SQZ 1.08.3e a -q6 312 000:17.1 187164 3.66
ZIP 1.9 -9 358 000:19.7 186430 4.20
SQZ 1.08.3e a -m1 383 000:21.0 186397 4.49
SQZ 1.08.3e a -q3 410 000:22.5 185635 4.81
SQZ 1.08.3e a -q0 509 000:28.0 185511 5.96
HAP3 3.00 a 1563 001:25.9 177294 18.32
>> Again, all four versions of PKZIP are the fastest to reach the levels
of compression that they reach.
>> This time three archivers out-do PKZIP in absolute size, but ARJ is
not one of them, ZIP does so by less than 300 bytes, and SQZ takes more
than twice as long to save just 1200 bytes.
>> Again, HAP gets 9000 bytes better compression than PKZIP:ex, but takes
six times as long and still suffers from terrible de-compression speed.
>> Again, you can forget about HYPER and LHA.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 1563 001:25.9 177294 1.00
SQZ 1.08.3e a -q0 509 000:28.0 185511 1.05
SQZ 1.08.3e a -q3 410 000:22.5 185635 1.05
SQZ 1.08.3e a -m1 383 000:21.0 186397 1.05
ZIP 1.9 -9 358 000:19.7 186430 1.05
ZIP 1.9 -6 293 000:16.1 186655 1.05
PKZIP 2.04g -a -ex 232 000:12.7 186710 1.05
SQZ 1.08.3e a -q6 312 000:17.1 187164 1.06
ARJ 2.39f a -jm 309 000:17.0 187238 1.06
ARJ 2.39f a -jm1 286 000:15.7 187311 1.06
ARJ 2.39f a -m1 286 000:15.7 187352 1.06
PKZIP 2.04g -a -en 173 000: 9.5 187603 1.06
ZIP 1.9 -3 233 000:12.8 188380 1.06
ZIP 1.9 -1 232 000:12.7 190853 1.08
LHA 2.52 a -n 306 000:16.8 191378 1.08
PKZIP 2.04g -a -ef 139 000: 7.6 192176 1.08
SQZ 1.08.3e a -q9 267 000:14.7 192453 1.09
ARJ 2.39f a -m3 183 000:10.1 192558 1.09
HYPER 2.5 -a 302 000:16.6 197280 1.11
PKZIP 2.04g -a -es 85 000: 4.7 202258 1.14
ARJ 2.39f a -m4 151 000: 8.3 204075 1.15
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-en) 40 000: 2.2 1.00
PKUNZIP 2.04g -e (-ef) 42 000: 2.3 1.05
PKUNZIP 2.04g -e (-ex) 45 000: 2.5 1.11
PKUNZIP 2.04g -e (-es) 57 000: 3.1 1.40
LHA 2.52 e -n 75 000: 4.1 1.85
SQZ 1.08.3e e (-m1) 93 000: 5.1 2.29
ARJ 2.39f e (-m4) 94 000: 5.2 2.31
ARJ 2.39f e (-jm1) 94 000: 5.2 2.33
SQZ 1.08.3e e (-q3) 94 000: 5.2 2.33
SQZ 1.08.3e e (-q6) 95 000: 5.2 2.35
SQZ 1.08.3e e (-q0) 96 000: 5.3 2.36
ARJ 2.39f e (-jm) 96 000: 5.3 2.38
ARJ 2.39f e (-m1) 97 000: 5.3 2.39
ARJ 2.39f e (-m3) 98 000: 5.4 2.41
SQZ 1.08.3e e (-q9) 99 000: 5.4 2.45
HYPER 2.5 -x 128 000: 7.0 3.15
UNZIP 5.00 -j (-9) 161 000: 8.8 3.98
UNZIP 5.00 -j (-6) 166 000: 9.1 4.09
UNZIP 5.00 -j (-3) 175 000: 9.6 4.31
UNZIP 5.00 -j (-1) 205 000:11.3 5.06
PAH3 3.00 e 624 000:34.3 15.34
>> This time PAH takes less than half the time to de-compress as HAP took
to compress. What's the deal?
╓──────────────────╖
║ Winners Set 5 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║
║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║
║ Category 3 (abs size): HAP best, then SQZ, then ZIP ║
║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 6 -----------------------------------------------------
Plain ASCII text files. They are captured discussions of the PK/SEA
debate from the message base on Magpie BBS.
magpie 48,000 bytes
magpie2 55,040 bytes
magpie3 50,944 bytes
magpie4 52,864 bytes
magpie5 120,576 bytes
magpie6 15,488 bytes
reply.txt 31,104 bytes
-------
374,016 total bytes in 7 files
DCCMP run as: "DCCMP -3 -ts -otest6.rsl archive test6 f:\test6\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:07:05
Total time elapsed: 0:21:16
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 65 000: 3.6 153115 1.00
PKZIP 2.04g -a -ef 107 000: 5.9 138362 1.66
ARJ 2.39f a -m4 122 000: 6.7 154303 1.89
ARJ 2.39f a -m3 142 000: 7.8 138231 2.18
PKZIP 2.04g -a -en 167 000: 9.2 130889 2.58
ZIP 1.9 -1 190 000:10.4 135739 2.92
ZIP 1.9 -3 208 000:11.4 131711 3.21
PKZIP 2.04g -a -ex 226 000:12.4 130007 3.49
HYPER 2.5 -a 236 000:13.0 140852 3.64
SQZ 1.08.3e a -q9 244 000:13.4 139090 3.76
ZIP 1.9 -6 249 000:13.7 129948 3.84
ARJ 2.39f a -m1 261 000:14.3 131146 4.02
ARJ 2.39f a -jm1 271 000:14.9 131127 4.17
ARJ 2.39f a -jm 277 000:15.2 131118 4.26
ZIP 1.9 -9 278 000:15.3 129903 4.28
LHA 2.52 a -n 323 000:17.7 138639 4.98
SQZ 1.08.3e a -q6 326 000:17.9 130770 5.02
SQZ 1.08.3e a -m1 400 000:22.0 130120 6.16
SQZ 1.08.3e a -q3 427 000:23.5 129360 6.57
SQZ 1.08.3e a -q0 477 000:26.2 129312 7.34
HAP3 3.00 a 707 000:38.8 109167 10.88
>> Again, look at how fast PKZIP reaches the levels of compression that it
does compared to the other archivers.
>> If you throw out the two faster versions of ARJ that don't get that great
of compression, then you'll see that ZIP performs better than ARJ.
>> Again, we have three archivers that out-do PKZIP in absolute compression
size. And again, ARJ is not one of them, ZIP barely does better, and SQZ
takes more than twice as long to get just 700 bytes better compression.
>> But this time, HAP gets more than 20000 bytes better compression. That's
20% better, and four times better than HAP did over the other archivers
in the last two test sets.
>> And HAP took only about three times as long as PKZIP:ex this time. This
shows that when HAP is compressing the best in terms of size, then it is
also at its best in terms of speed, which makes sense.
>> This test set also shows that HAP is very good at English text, and
conversely, that HAP is poor with binary files. If, HAP analyzed the data
before compressing it, and then applied PKZIP's algorithm on binary files,
and its own algorithm in ASCII text, then HAP would likely compress not only
smaller, but faster (since only the text files would be slow).
>> Again, we can forget about HYPER and LHA.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 707 000:38.8 109167 1.00
SQZ 1.08.3e a -q0 477 000:26.2 129312 1.18
SQZ 1.08.3e a -q3 427 000:23.5 129360 1.18
ZIP 1.9 -9 278 000:15.3 129903 1.19
ZIP 1.9 -6 249 000:13.7 129948 1.19
PKZIP 2.04g -a -ex 226 000:12.4 130007 1.19
SQZ 1.08.3e a -m1 400 000:22.0 130120 1.19
SQZ 1.08.3e a -q6 326 000:17.9 130770 1.20
PKZIP 2.04g -a -en 167 000: 9.2 130889 1.20
ARJ 2.39f a -jm 277 000:15.2 131118 1.20
ARJ 2.39f a -jm1 271 000:14.9 131127 1.20
ARJ 2.39f a -m1 261 000:14.3 131146 1.20
ZIP 1.9 -3 208 000:11.4 131711 1.21
ZIP 1.9 -1 190 000:10.4 135739 1.24
ARJ 2.39f a -m3 142 000: 7.8 138231 1.27
PKZIP 2.04g -a -ef 107 000: 5.9 138362 1.27
LHA 2.52 a -n 323 000:17.7 138639 1.27
SQZ 1.08.3e a -q9 244 000:13.4 139090 1.27
HYPER 2.5 -a 236 000:13.0 140852 1.29
PKZIP 2.04g -a -es 65 000: 3.6 153115 1.40
ARJ 2.39f a -m4 122 000: 6.7 154303 1.41
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
UNZIP 5.00 -j (-6) 17 000: 0.9 1.00
UNZIP 5.00 -j (-9) 17 000: 0.9 1.02
UNZIP 5.00 -j (-3) 17 000: 0.9 1.02
UNZIP 5.00 -j (-1) 31 000: 1.7 1.79
PKUNZIP 2.04g -e (-ef) 33 000: 1.8 1.92
PKUNZIP 2.04g -e (-en) 33 000: 1.8 1.94
PKUNZIP 2.04g -e (-ex) 35 000: 1.9 2.06
PKUNZIP 2.04g -e (-es) 48 000: 2.6 2.79
LHA 2.52 e -n 56 000: 3.1 3.27
ARJ 2.39f e (-m1) 68 000: 3.7 3.94
ARJ 2.39f e (-jm) 69 000: 3.8 4.00
ARJ 2.39f e (-jm1) 70 000: 3.8 4.08
SQZ 1.08.3e e (-q0) 70 000: 3.8 4.08
SQZ 1.08.3e e (-q3) 71 000: 3.9 4.12
ARJ 2.39f e (-m3) 71 000: 3.9 4.13
SQZ 1.08.3e e (-q6) 72 000: 4.0 4.15
SQZ 1.08.3e e (-q9) 75 000: 4.1 4.37
SQZ 1.08.3e e (-m1) 77 000: 4.2 4.48
ARJ 2.39f e (-m4) 83 000: 4.6 4.79
HYPER 2.5 -x 163 000: 9.0 9.40
PAH3 3.00 e 798 000:43.8 46.06
>> Look at this! UNZIP which was previously 4 or 5 times slower than
PKUNZIP, is now about twice as fast. The main difference with this
test set is that the matched strings would be considerably longer
than in the other test sets (ie, the test set is more compressible).
╓──────────────────╖
║ Winners Set 6 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ZIP, then ARJ ║
║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║
║ Category 3 (abs size): HAP best, then SQZ, then ZIP ║
║ Category 4 (extract) : ZIP best, then PKZIP, then ARJ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 7 -----------------------------------------------------
These are files from some version of DOS with all files over 9999 bytes
removed.
mortgage.bas 6,251 bytes
assign.com 1,561 bytes
basic.com 1,063 bytes
chkdsk.com 9,850 bytes
comp.com 4,214 bytes
diskcomp.com 5,879 bytes
diskcopy.com 6,295 bytes
diskpark.com 2,790 bytes
edlin.com 7,526 bytes
graftabl.com 6,128 bytes
graphics.com 3,300 bytes
keyb.com 9,056 bytes
label.com 2,377 bytes
more.com 313 bytes
print.com 9,026 bytes
recover.com 4,299 bytes
select.com 4,163 bytes
sys.com 4,766 bytes
tree.com 3,571 bytes
5202.cpi 459 bytes
append.exe 5,825 bytes
attrib.exe 9,529 bytes
fastopen.exe 3,919 bytes
find.exe 6,434 bytes
join.exe 8,969 bytes
nlsfunc.exe 3,060 bytes
share.exe 8,608 bytes
sort.exe 1,977 bytes
subst.exe 9,909 bytes
basic.pif 369 bytes
basica.pif 369 bytes
diskpark.ref 2,304 bytes
ansi.sys 1,678 bytes
driver.sys 1,196 bytes
vdisk.sys 3,455 bytes
-------
160,488 total bytes in 35 files
DCCMP run as: "DCCMP -3 -ts -otest7.rsl archive test7 f:\test7\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:05:52
Total time elapsed: 0:17:38
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 62 000: 3.4 93964 1.00
PKZIP 2.04g -a -ef 80 000: 4.4 90523 1.28
PKZIP 2.04g -a -en 81 000: 4.5 90310 1.31
PKZIP 2.04g -a -ex 93 000: 5.1 90310 1.50
ARJ 2.39f a -m4 101 000: 5.5 98895 1.63
SQZ 1.08.3e a -q9 133 000: 7.3 88351 2.13
LHA 2.52 a -n 135 000: 7.4 88238 2.17
ZIP 1.9 -1 142 000: 7.8 90941 2.29
ZIP 1.9 -3 143 000: 7.9 90751 2.30
ARJ 2.39f a -m3 144 000: 7.9 89627 2.32
SQZ 1.08.3e a -q6 147 000: 8.1 88116 2.36
ARJ 2.39f a -jm1 148 000: 8.1 89043 2.38
ZIP 1.9 -6 148 000: 8.1 90647 2.38
ARJ 2.39f a -jm 152 000: 8.4 89037 2.44
ZIP 1.9 -9 155 000: 8.5 90634 2.50
HYPER 2.5 -a 160 000: 8.8 91300 2.57
SQZ 1.08.3e a -q3 162 000: 8.9 88107 2.60
ARJ 2.39f a -m1 173 000: 9.5 89024 2.78
SQZ 1.08.3e a -m1 179 000: 9.8 88229 2.88
SQZ 1.08.3e a -q0 189 000:10.4 88114 3.04
HAP3 3.00 a 825 000:45.3 87192 13.24
>> With this set of small binary files, we have a different set of winners.
However, the differences in size between 1st, 2nd, and 3rd place winners
are often very small.
>> Notice that all four levels of PKZIP are faster than any other archiver.
That means that even the SLOWEST level of PKZIP (PKZIP:ex) is faster than
the FASTEST level of any other archiver.
>> Even so, PKZIP can't manage to get down to the 88000 byte level that both
SQZ and LHA do. And it can't get down to the 89000 byte level that ARJ
does. At least you can say that LHA has an advantage in that it uses
small file headers, but ARJ does not have this advantage and still beats
PKZIP. (Remember that the larger file headers allow for more integrity
and features).
>> Finally, LHA wins in a Category (the size Category), although just barely
over SQZ. LHA compresses a little faster, SQZ compresses a tiny bit
better.
>> While LHA and SQZ are very close to each other, ARJ is definitely behind
them for third place.
>> Notice how poorly ARJ:m4 performs. Is this the price you want to pay for
speed? And remember that the slowest level of PKZIP was still faster than
this "fast" level of ARJ.
>> HYPER remains unremarkable.
>> And if want to wait seven times longer than LHA, then HAP will save you
1000 bytes, but require you to wait 26 times longer than PKUNZIP to
extract.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 825 000:45.3 87192 1.00
SQZ 1.08.3e a -q3 162 000: 8.9 88107 1.01
SQZ 1.08.3e a -q0 189 000:10.4 88114 1.01
SQZ 1.08.3e a -q6 147 000: 8.1 88116 1.01
SQZ 1.08.3e a -m1 179 000: 9.8 88229 1.01
LHA 2.52 a -n 135 000: 7.4 88238 1.01
SQZ 1.08.3e a -q9 133 000: 7.3 88351 1.01
ARJ 2.39f a -m1 173 000: 9.5 89024 1.02
ARJ 2.39f a -jm 152 000: 8.4 89037 1.02
ARJ 2.39f a -jm1 148 000: 8.1 89043 1.02
ARJ 2.39f a -m3 144 000: 7.9 89627 1.03
PKZIP 2.04g -a -en 81 000: 4.5 90310 1.04
PKZIP 2.04g -a -ex 93 000: 5.1 90310 1.04
PKZIP 2.04g -a -ef 80 000: 4.4 90523 1.04
ZIP 1.9 -9 155 000: 8.5 90634 1.04
ZIP 1.9 -6 148 000: 8.1 90647 1.04
ZIP 1.9 -3 143 000: 7.9 90751 1.04
ZIP 1.9 -1 142 000: 7.8 90941 1.04
HYPER 2.5 -a 160 000: 8.8 91300 1.05
PKZIP 2.04g -a -es 62 000: 3.4 93964 1.08
ARJ 2.39f a -m4 101 000: 5.5 98895 1.13
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-es) 39 000: 2.1 1.00
PKUNZIP 2.04g -e (-en) 39 000: 2.1 1.00
PKUNZIP 2.04g -e (-ef) 40 000: 2.2 1.01
PKUNZIP 2.04g -e (-ex) 42 000: 2.3 1.06
LHA 2.52 e -n 60 000: 3.3 1.52
SQZ 1.08.3e e (-q3) 73 000: 4.0 1.84
SQZ 1.08.3e e (-q9) 73 000: 4.0 1.85
SQZ 1.08.3e e (-m1) 73 000: 4.0 1.86
SQZ 1.08.3e e (-q0) 74 000: 4.1 1.87
SQZ 1.08.3e e (-q6) 74 000: 4.1 1.87
ARJ 2.39f e (-jm) 102 000: 5.6 2.59
ARJ 2.39f e (-m3) 104 000: 5.7 2.62
ARJ 2.39f e (-jm1) 104 000: 5.7 2.62
UNZIP 5.00 -j (-3) 104 000: 5.7 2.64
ARJ 2.39f e (-m4) 106 000: 5.8 2.67
UNZIP 5.00 -j (-6) 107 000: 5.9 2.71
UNZIP 5.00 -j (-9) 108 000: 5.9 2.74
ARJ 2.39f e (-m1) 111 000: 6.1 2.81
UNZIP 5.00 -j (-1) 126 000: 6.9 3.18
HYPER 2.5 -x 133 000: 7.3 3.35
PAH3 3.00 e 1067 000:58.6 26.90
>> This time UNZIPis about as fast extracting as ARJ is.
>> But, of course, PKUNZIP is the clear winner at extraction.
╓──────────────────╖
║ Winners Set 7 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : LHA best, then SQZ, then ARJ ║
║ Category 2 (speed) : PKZIP best, then SQZ, then LHA ║
║ Category 3 (abs size): HAP best, then SQZ, then LHA ║
║ Category 4 (extract) : PKZIP best, then LHA, then SQZ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 8 -----------------------------------------------------
C and assembler source files from Small Windows (a text mode windowing
library). All files are less than 10,000 bytes.
files.c 6,780 bytes
itoab.c 598 bytes
itou.c 567 bytes
ltou.c 709 bytes
menu.c 8,422 bytes
msort.c 2,076 bytes
poll.c 512 bytes
swtest.c 9,728 bytes
utoi.c 398 bytes
vmode.c 792 bytes
vpoint.c 761 bytes
watt.c 556 bytes
wauto.c 736 bytes
wchr.c 550 bytes
wchra.c 590 bytes
wclean.c 448 bytes
wframe.c 1,574 bytes
wgetc.c 640 bytes
wgetf.c 4,072 bytes
wgets.c 1,376 bytes
whorlin.c 768 bytes
wkernel.c 9,472 bytes
wmove.c 1,295 bytes
wprintf.c 2,176 bytes
wprintfa.c 2,593 bytes
wpush.c 965 bytes
wputc.c 672 bytes
wputca.c 741 bytes
wputs.c 243 bytes
wputsa.c 348 bytes
wreada.c 640 bytes
wscanf.c 2,766 bytes
wscroll.c 2,197 bytes
wstr.c 567 bytes
wstra.c 592 bytes
wverlin.c 768 bytes
window.h 1,242 bytes
files2.asm 7,168 bytes
getkey.asm 1,280 bytes
hitkey.asm 1,024 bytes
pad.asm 1,280 bytes
vatt.asm 2,688 bytes
vchr.asm 2,688 bytes
vchra.asm 2,944 bytes
vcursor.asm 1,280 bytes
vdrop.asm 1,664 bytes
vgoto.asm 1,280 bytes
visat.asm 1,152 bytes
vlift.asm 1,664 bytes
vmode2.asm 1,408 bytes
vpage.asm 1,280 bytes
vpoint2.asm 768 bytes
vreada.asm 2,432 bytes
vshow.asm 3,328 bytes
vstow.asm 3,200 bytes
vstr.asm 3,840 bytes
vstra.asm 4,224 bytes
-------
116,522 total bytes in 57 files
DCCMP run as: "DCCMP -3 -ts -otest8.rsl archive test8 f:\test8\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:04:59
Total time elapsed: 0:14:58
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 61 000: 3.4 45524 1.00
PKZIP 2.04g -a -ef 67 000: 3.7 42473 1.10
PKZIP 2.04g -a -en 69 000: 3.8 42007 1.14
PKZIP 2.04g -a -ex 76 000: 4.2 41904 1.25
ARJ 2.39f a -m4 115 000: 6.3 45932 1.89
SQZ 1.08.3e a -q9 120 000: 6.6 39409 1.98
ZIP 1.9 -1 122 000: 6.7 43348 2.00
ZIP 1.9 -3 124 000: 6.8 42919 2.04
LHA 2.52 a -n 127 000: 7.0 38689 2.09
SQZ 1.08.3e a -q6 128 000: 7.0 38669 2.10
ZIP 1.9 -6 131 000: 7.2 42604 2.16
ARJ 2.39f a -m3 133 000: 7.3 41025 2.19
HYPER 2.5 -a 135 000: 7.4 40977 2.22
ZIP 1.9 -9 139 000: 7.6 42548 2.29
ARJ 2.39f a -jm1 148 000: 8.1 39952 2.43
SQZ 1.08.3e a -q3 150 000: 8.2 38468 2.46
ARJ 2.39f a -jm 152 000: 8.4 39923 2.50
SQZ 1.08.3e a -m1 168 000: 9.2 38714 2.75
SQZ 1.08.3e a -q0 176 000: 9.7 38438 2.89
ARJ 2.39f a -m1 227 000:12.5 39968 3.72
HAP3 3.00 a 432 000:23.7 37720 7.09
>> This time the test set a bunch of small ASCII files, but the outcome is
basically the same as the last test set (the set of small binary files).
>> This time SQZ is slightly better than LHA. Why not just say they are
equal on small files? (Unless, of course, one is only counting absolute
file sizes.)
>> Again, all four levels of PKZIP are faster than anything else.
>> This time, the fastest level of ARJ does not do so poorly.
>> And this time, HYPER gets better compression than PKZIP. That's five
archivers that get better compression than PKZIP! Though they only save
at best 3500 bytes (not including HAP), this is a significant percentage
(about 9%).
>> Notice that ZIP, that uses the same algorithm as PKZIP, is also poor in
compression size.
>> Again, HAP only compresses a little better though it take three times as
long as LHA.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 432 000:23.7 37720 1.00
SQZ 1.08.3e a -q0 176 000: 9.7 38438 1.02
SQZ 1.08.3e a -q3 150 000: 8.2 38468 1.02
SQZ 1.08.3e a -q6 128 000: 7.0 38669 1.03
LHA 2.52 a -n 127 000: 7.0 38689 1.03
SQZ 1.08.3e a -m1 168 000: 9.2 38714 1.03
SQZ 1.08.3e a -q9 120 000: 6.6 39409 1.04
ARJ 2.39f a -jm 152 000: 8.4 39923 1.06
ARJ 2.39f a -jm1 148 000: 8.1 39952 1.06
ARJ 2.39f a -m1 227 000:12.5 39968 1.06
HYPER 2.5 -a 135 000: 7.4 40977 1.09
ARJ 2.39f a -m3 133 000: 7.3 41025 1.09
PKZIP 2.04g -a -ex 76 000: 4.2 41904 1.11
PKZIP 2.04g -a -en 69 000: 3.8 42007 1.11
PKZIP 2.04g -a -ef 67 000: 3.7 42473 1.13
ZIP 1.9 -9 139 000: 7.6 42548 1.13
ZIP 1.9 -6 131 000: 7.2 42604 1.13
ZIP 1.9 -3 124 000: 6.8 42919 1.14
ZIP 1.9 -1 122 000: 6.7 43348 1.15
PKZIP 2.04g -a -es 61 000: 3.4 45524 1.21
ARJ 2.39f a -m4 115 000: 6.3 45932 1.22
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-ex) 51 000: 2.8 1.00
PKUNZIP 2.04g -e (-es) 53 000: 2.9 1.05
PKUNZIP 2.04g -e (-en) 56 000: 3.1 1.11
PKUNZIP 2.04g -e (-ef) 59 000: 3.2 1.17
LHA 2.52 e -n 69 000: 3.8 1.36
SQZ 1.08.3e e (-q3) 77 000: 4.2 1.52
SQZ 1.08.3e e (-q0) 77 000: 4.2 1.52
SQZ 1.08.3e e (-m1) 78 000: 4.3 1.53
SQZ 1.08.3e e (-q9) 78 000: 4.3 1.54
SQZ 1.08.3e e (-q6) 79 000: 4.3 1.55
UNZIP 5.00 -j (-9) 86 000: 4.7 1.69
UNZIP 5.00 -j (-3) 90 000: 4.9 1.78
UNZIP 5.00 -j (-6) 92 000: 5.1 1.81
UNZIP 5.00 -j (-1) 96 000: 5.3 1.90
HYPER 2.5 -x 103 000: 5.7 2.02
ARJ 2.39f e (-m4) 125 000: 6.9 2.46
ARJ 2.39f e (-m3) 128 000: 7.0 2.52
ARJ 2.39f e (-jm) 128 000: 7.0 2.52
ARJ 2.39f e (-jm1) 129 000: 7.1 2.54
ARJ 2.39f e (-m1) 158 000: 8.7 3.10
PAH3 3.00 e 489 000:26.9 9.59
>> Here UNZIP decidedly beats ARJ in extraction.
╓──────────────────╖
║ Winners Set 8 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : SQZ best, then LHA, then ARJ ║
║ Category 2 (speed) : PKZIP best, then SQZ, then LHA ║
║ Category 3 (abs size): HAP best, then SQZ, then LHA ║
║ Category 4 (extract) : PKZIP best, then LHA, then SQZ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 9 -----------------------------------------------------
King James translation of PSALMS. Mostly ASCII, with binary codes
between each verse.
19o_psal.kj 228,638 bytes
DCCMP run as: "DCCMP -3 -ts -otest9.rsl archive test9 f:\test9\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:05:19
Total time elapsed: 0:15:58
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 46 000: 2.5 99318 1.00
ARJ 2.39f a -m4 75 000: 4.1 97311 1.64
PKZIP 2.04g -a -ef 82 000: 4.5 87021 1.80
ARJ 2.39f a -m3 89 000: 4.9 86641 1.95
PKZIP 2.04g -a -en 127 000: 7.0 79847 2.78
ZIP 1.9 -1 130 000: 7.1 84160 2.83
ZIP 1.9 -3 142 000: 7.8 81123 3.09
HYPER 2.5 -a 148 000: 8.1 87013 3.22
SQZ 1.08.3e a -q9 158 000: 8.7 88414 3.45
ZIP 1.9 -6 194 000:10.7 79103 4.22
LHA 2.52 a -n 209 000:11.5 86380 4.55
ARJ 2.39f a -m1 209 000:11.5 80336 4.56
PKZIP 2.04g -a -ex 222 000:12.2 78827 4.84
ARJ 2.39f a -jm1 228 000:12.5 80167 4.96
SQZ 1.08.3e a -q6 231 000:12.7 80946 5.04
ARJ 2.39f a -jm 240 000:13.2 80108 5.22
ZIP 1.9 -9 250 000:13.7 78753 5.44
SQZ 1.08.3e a -m1 301 000:16.5 79945 6.54
SQZ 1.08.3e a -q3 362 000:19.9 78792 7.88
HAP3 3.00 a 402 000:22.1 64993 8.75
SQZ 1.08.3e a -q0 452 000:24.8 78483 9.83
>> This is the first test set that HAP wins Category 1 (best size with ok
speed). HAP takes 81% longer time than PKZIP:ex, but gets 21% better
compression! Of course, you'll have to wait 21 times longer than
PKUNZIP to extract with PAH.
>> Again, this shows that HAP's strength is in English text. HAP probably
does just as well in other languages, I just didn't have anything in
other languages to test. Please remember that you can use my DCCMP
program to test out you own files.
>> Here, PKZIP:es compresses 2000 bytes larger than ARJ:m4, but it does so
in less than half the time.
>> PKZIP:ef is about the same as ARJ:m3. A little faster, but a little
worse compression.
>> After that, though, both PKZIP and ZIP out perform ARJ.
>> And you can go back to forgetting about LHA and HYPER.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 402 000:22.1 64993 1.00
SQZ 1.08.3e a -q0 452 000:24.8 78483 1.21
ZIP 1.9 -9 250 000:13.7 78753 1.21
SQZ 1.08.3e a -q3 362 000:19.9 78792 1.21
PKZIP 2.04g -a -ex 222 000:12.2 78827 1.21
ZIP 1.9 -6 194 000:10.7 79103 1.22
PKZIP 2.04g -a -en 127 000: 7.0 79847 1.23
SQZ 1.08.3e a -m1 301 000:16.5 79945 1.23
ARJ 2.39f a -jm 240 000:13.2 80108 1.23
ARJ 2.39f a -jm1 228 000:12.5 80167 1.23
ARJ 2.39f a -m1 209 000:11.5 80336 1.24
SQZ 1.08.3e a -q6 231 000:12.7 80946 1.25
ZIP 1.9 -3 142 000: 7.8 81123 1.25
ZIP 1.9 -1 130 000: 7.1 84160 1.29
LHA 2.52 a -n 209 000:11.5 86380 1.33
ARJ 2.39f a -m3 89 000: 4.9 86641 1.33
HYPER 2.5 -a 148 000: 8.1 87013 1.34
PKZIP 2.04g -a -ef 82 000: 4.5 87021 1.34
SQZ 1.08.3e a -q9 158 000: 8.7 88414 1.36
ARJ 2.39f a -m4 75 000: 4.1 97311 1.50
PKZIP 2.04g -a -es 46 000: 2.5 99318 1.53
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-en) 21 000: 1.2 1.00
PKUNZIP 2.04g -e (-ef) 22 000: 1.2 1.05
PKUNZIP 2.04g -e (-ex) 22 000: 1.2 1.05
PKUNZIP 2.04g -e (-es) 28 000: 1.5 1.33
LHA 2.52 e -n 34 000: 1.9 1.61
ARJ 2.39f e (-jm) 40 000: 2.2 1.88
ARJ 2.39f e (-jm1) 40 000: 2.2 1.88
ARJ 2.39f e (-m1) 40 000: 2.2 1.89
SQZ 1.08.3e e (-m1) 41 000: 2.3 1.95
SQZ 1.08.3e e (-q0) 42 000: 2.3 1.98
ARJ 2.39f e (-m3) 42 000: 2.3 2.00
SQZ 1.08.3e e (-q3) 42 000: 2.3 2.00
SQZ 1.08.3e e (-q6) 44 000: 2.4 2.09
SQZ 1.08.3e e (-q9) 46 000: 2.5 2.19
ARJ 2.39f e (-m4) 50 000: 2.7 2.38
UNZIP 5.00 -j (-6) 80 000: 4.4 3.78
UNZIP 5.00 -j (-9) 81 000: 4.5 3.81
UNZIP 5.00 -j (-3) 86 000: 4.7 4.03
HYPER 2.5 -x 99 000: 5.4 4.64
UNZIP 5.00 -j (-1) 103 000: 5.7 4.83
PAH3 3.00 e 457 000:25.1 21.45
>> UNZIP is now back to its usual 4 times slower than PKUNZIP spot.
╓──────────────────╖
║ Winners Set 9 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : HAP best, then PKZIP, then ZIP ║
║ Category 2 (speed) : PKZIP best, then ARJ, then ZIP ║
║ Category 3 (abs size): HAP best, then SQZ, then ZIP ║
║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 10 -----------------------------------------------------
Lotus 1-2-3 files. These spreadsheets are from where I work.
annulus1.wk1 24,876 bytes
beamleaf.wk1 32,028 bytes
exp.wk1 29,000 bytes
motion1.wk1 93,230 bytes
motion2.wk1 109,830 bytes
-------
288,964 total bytes in 5 files
DCCMP run as: "DCCMP -3 -ts -otest10.rsl archive test10 f:\test10\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:07:40
Total time elapsed: 0:23:01
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 40 000: 2.2 63900 1.00
PKZIP 2.04g -a -ef 74 000: 4.1 63385 1.84
ARJ 2.39f a -m4 80 000: 4.4 78277 2.00
ARJ 2.39f a -m3 95 000: 5.2 64114 2.36
ZIP 1.9 -1 127 000: 7.0 64912 3.15
ZIP 1.9 -3 134 000: 7.4 61820 3.34
PKZIP 2.04g -a -en 140 000: 7.7 61658 3.49
SQZ 1.08.3e a -q9 145 000: 8.0 63280 3.60
HYPER 2.5 -a 152 000: 8.4 59309 3.79
LHA 2.52 a -n 184 000:10.1 63078 4.57
SQZ 1.08.3e a -q6 204 000:11.2 61548 5.07
ARJ 2.39f a -m1 213 000:11.7 59759 5.29
PKZIP 2.04g -a -ex 219 000:12.0 61136 5.43
ZIP 1.9 -6 238 000:13.1 59969 5.91
ARJ 2.39f a -jm1 252 000:13.8 59748 6.26
SQZ 1.08.3e a -m1 286 000:15.7 64196 7.09
ARJ 2.39f a -jm 306 000:16.8 59743 7.59
SQZ 1.08.3e a -q3 548 000:30.1 63386 13.60
HAP3 3.00 a 655 000:36.0 56849 16.26
ZIP 1.9 -9 848 000:46.6 59904 21.02
SQZ 1.08.3e a -q0 1583 001:27.0 63372 39.25
>> Finally HYPER wins Category 1 (best size with ok speed).
>> This time HAP's compression speed is ok (read not terrible), but it only
gets 4% better compression (instead of the 21% better as on the last
test).
>> This time the first two level of PKZIP get good compression quickly, but
ZIP:3 equals PKZIP:en, and ARJ:m1 is both faster and better compressing
than PKZIP:ex. Not only that, but ARJ:m1 itself is beat by HYPER in both
speed and size.
>> Indeed, PKZIP:ex is beaten by four archivers, though none of them is SQZ.
Of course, except for HAP, none of the archivers beat PKZIP by much (at
most by 800 bytes).
>> Notice how SQZ:q6 compresses 2000 bytes better than SQZ:q0. And it does
so in 1/8 of the time. Remember that level q0 is supposed to compress
better than level q6 (the lower the number, the better the compression).
As you must surely have seen by now, nothing with archivers is a sure
thing.
>> Indeed, in this test case, SQZ:q0 is 2 and a half times SLOWER than HAP!
>> Even ZIP:9 is slower than HAP.
>> Still, HYPER is only 2500 bytes larger than HAP while being 4 times
faster (that's 11 times faster than SQZ:q0).
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
HAP3 3.00 a 655 000:36.0 56849 1.00
HYPER 2.5 -a 152 000: 8.4 59309 1.04
ARJ 2.39f a -jm 306 000:16.8 59743 1.05
ARJ 2.39f a -jm1 252 000:13.8 59748 1.05
ARJ 2.39f a -m1 213 000:11.7 59759 1.05
ZIP 1.9 -9 848 000:46.6 59904 1.05
ZIP 1.9 -6 238 000:13.1 59969 1.05
PKZIP 2.04g -a -ex 219 000:12.0 61136 1.08
SQZ 1.08.3e a -q6 204 000:11.2 61548 1.08
PKZIP 2.04g -a -en 140 000: 7.7 61658 1.08
ZIP 1.9 -3 134 000: 7.4 61820 1.09
LHA 2.52 a -n 184 000:10.1 63078 1.11
SQZ 1.08.3e a -q9 145 000: 8.0 63280 1.11
SQZ 1.08.3e a -q0 1583 001:27.0 63372 1.11
PKZIP 2.04g -a -ef 74 000: 4.1 63385 1.11
SQZ 1.08.3e a -q3 548 000:30.1 63386 1.11
PKZIP 2.04g -a -es 40 000: 2.2 63900 1.12
ARJ 2.39f a -m3 95 000: 5.2 64114 1.13
SQZ 1.08.3e a -m1 286 000:15.7 64196 1.13
ZIP 1.9 -1 127 000: 7.0 64912 1.14
ARJ 2.39f a -m4 80 000: 4.4 78277 1.38
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-en) 23 000: 1.3 1.00
PKUNZIP 2.04g -e (-es) 24 000: 1.3 1.01
PKUNZIP 2.04g -e (-ef) 24 000: 1.3 1.03
PKUNZIP 2.04g -e (-ex) 25 000: 1.4 1.06
LHA 2.52 e -n 32 000: 1.8 1.35
SQZ 1.08.3e e (-m1) 44 000: 2.4 1.87
SQZ 1.08.3e e (-q3) 45 000: 2.5 1.90
SQZ 1.08.3e e (-q0) 45 000: 2.5 1.90
SQZ 1.08.3e e (-q6) 45 000: 2.5 1.92
SQZ 1.08.3e e (-q9) 46 000: 2.5 1.94
ARJ 2.39f e (-jm1) 48 000: 2.6 2.04
ARJ 2.39f e (-jm) 48 000: 2.6 2.04
ARJ 2.39f e (-m1) 48 000: 2.6 2.04
ARJ 2.39f e (-m3) 49 000: 2.7 2.10
ARJ 2.39f e (-m4) 54 000: 3.0 2.31
UNZIP 5.00 -j (-9) 77 000: 4.2 3.25
UNZIP 5.00 -j (-6) 79 000: 4.3 3.37
UNZIP 5.00 -j (-3) 86 000: 4.7 3.63
HYPER 2.5 -x 87 000: 4.8 3.69
UNZIP 5.00 -j (-1) 98 000: 5.4 4.15
PAH3 3.00 e 763 000:41.9 32.25
>> Although HYPER may win once in compression, it loses in extraction by
being 3 and half times slower than PKUNZIP.
>> And again, PAH is 32 times slower than PKUNZIP.
╓──────────────────╖
║ Winners Set 10 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : HYPER best, then ARJ, then ZIP ║
║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║
║ Category 3 (abs size): HAP best, then HYPER, then ARJ ║
║ Category 4 (extract) : PKZIP best, then SQZ, then ARJ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 11 -----------------------------------------------------
Microsoft Visual C++ windows help file for the Microsoft Foundation
Classes.
mfc.hlp 2,222,523 bytes
DCCMP run as: "DCCMP -3 -ts -otest11.rsl archive test11 f:\test11\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 1:18:23
Total time elapsed: 3:55:11
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 730 000:40.1 1361988 1.00
ARJ 2.39f a -m4 905 000:49.7 1552530 1.24
PKZIP 2.04g -a -ef 1045 000:57.4 1324195 1.43
ARJ 2.39f a -m3 1181 001: 4.9 1345337 1.62
PKZIP 2.04g -a -en 1427 001:18.4 1253792 1.95
ZIP 1.9 -1 1451 001:19.7 1257140 1.99
ZIP 1.9 -3 1618 001:28.9 1247798 2.22
SQZ 1.08.3e a -q9 1751 001:36.2 1265875 2.40
ZIP 1.9 -6 1941 001:46.6 1242726 2.66
SQZ 1.08.3e a -q6 2001 001:49.9 1245526 2.74
HYPER 2.5 -a 2031 001:51.6 1442831 2.78
ARJ 2.39f a -m1 2036 001:51.9 1261364 2.79
PKZIP 2.04g -a -ex 2137 001:57.4 1237261 2.93
ARJ 2.39f a -jm1 2307 002: 6.8 1259420 3.16
SQZ 1.08.3e a -m1 2318 002: 7.4 1244060 3.18
SQZ 1.08.3e a -q3 2746 002:30.9 1241057 3.76
ARJ 2.39f a -jm 3533 003:14.1 1257307 4.84
ZIP 1.9 -9 3746 003:25.8 1238308 5.13
SQZ 1.08.3e a -q0 6060 005:33.0 1236629 8.30
HAP3 3.00 a 13449 012:19.0 1516570 18.42
>> This time HAP does terrible in compression. It takes HAP 6 times longer
than PKZIP:ex to get 23% worse compression. And if that's not bad enough
for you, it will take PAH FIFTY times longer than PKUNZIP to extract!
>> Good grief! With PKUNZIP you only have to wait 18 seconds, but with PAH,
you have to wait almost 16 MINUTES!! AND you're archive will be 280K
larger with HAP.
>> The moral of the story is that you better be very careful with what files
you use HAP on. That is, if you decide to use HAP at all.
>> These big files really show the differences between the archivers. For
example, although SQZ:q0 does compress 0.05% better than PKZIP:ex, it
takes almost 3 times longer to do it. And that means waiting around
3 and a half minutes longer.
>> At the next levels ZIP:6, ZIP:3, and SQZ:q6 do pretty good and are fairly
close to matching PKZIP.
>> But ARJ clearly lags behind.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
SQZ 1.08.3e a -q0 6060 005:33.0 1236629 1.00
PKZIP 2.04g -a -ex 2137 001:57.4 1237261 1.00
ZIP 1.9 -9 3746 003:25.8 1238308 1.00
SQZ 1.08.3e a -q3 2746 002:30.9 1241057 1.00
ZIP 1.9 -6 1941 001:46.6 1242726 1.00
SQZ 1.08.3e a -m1 2318 002: 7.4 1244060 1.01
SQZ 1.08.3e a -q6 2001 001:49.9 1245526 1.01
ZIP 1.9 -3 1618 001:28.9 1247798 1.01
PKZIP 2.04g -a -en 1427 001:18.4 1253792 1.01
ZIP 1.9 -1 1451 001:19.7 1257140 1.02
ARJ 2.39f a -jm 3533 003:14.1 1257307 1.02
ARJ 2.39f a -jm1 2307 002: 6.8 1259420 1.02
ARJ 2.39f a -m1 2036 001:51.9 1261364 1.02
SQZ 1.08.3e a -q9 1751 001:36.2 1265875 1.02
PKZIP 2.04g -a -ef 1045 000:57.4 1324195 1.07
ARJ 2.39f a -m3 1181 001: 4.9 1345337 1.09
PKZIP 2.04g -a -es 730 000:40.1 1361988 1.10
HYPER 2.5 -a 2031 001:51.6 1442831 1.17
HAP3 3.00 a 13449 012:19.0 1516570 1.23
ARJ 2.39f a -m4 905 000:49.7 1552530 1.26
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
LHA 2.52 a -n ERROR: Exit value of: 2
LHA 2.52 e -n ERROR: Exit value of: 2
PKUNZIP 2.04g -e (-ex) 340 000:18.7 1.00
PKUNZIP 2.04g -e (-en) 344 000:18.9 1.01
PKUNZIP 2.04g -e (-ef) 351 000:19.3 1.03
PKUNZIP 2.04g -e (-es) 353 000:19.4 1.04
ARJ 2.39f e (-jm1) 474 000:26.0 1.39
ARJ 2.39f e (-jm) 475 000:26.1 1.40
ARJ 2.39f e (-m1) 476 000:26.2 1.40
ARJ 2.39f e (-m3) 547 000:30.1 1.61
SQZ 1.08.3e e (-q0) 610 000:33.5 1.79
SQZ 1.08.3e e (-q3) 659 000:36.2 1.94
SQZ 1.08.3e e (-m1) 660 000:36.3 1.94
SQZ 1.08.3e e (-q6) 669 000:36.8 1.97
SQZ 1.08.3e e (-q9) 677 000:37.2 1.99
ARJ 2.39f e (-m4) 689 000:37.9 2.03
UNZIP 5.00 -j (-9) 1040 000:57.1 3.06
UNZIP 5.00 -j (-6) 1076 000:59.1 3.16
UNZIP 5.00 -j (-3) 1083 000:59.5 3.18
UNZIP 5.00 -j (-1) 1099 001: 0.4 3.23
HYPER 2.5 -x 1699 001:33.4 4.99
PAH3 3.00 e 17205 015:45.3 50.56
>> Here, LHA failed to compress the files because my RAM disk (which LHA
used because of my TMP or TEMP environment variable) did not have enough
room to hold the temporary archive file. This is really not LHA's fault,
but LHA never did that great anyway, so I didn't bother to re-run the
test.
╓──────────────────╖
║ Winners Set 11 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║
║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║
║ Category 3 (abs size): SQZ best, then PKZIP, then ZIP ║
║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║
╙─────────────────────────────────────────────────────────╜
---- TEST SET 12 -----------------------------------------------------
Two large executable files from Microsoft Visual C++.
apstudio.exe 880,288 bytes
msvc.exe 772,208 bytes
-------
1,652,496 total bytes in 2 files
DCCMP run as: "DCCMP -3 -ts -otest12.rsl archive test12 f:\test12\*.* f:\temp *.*"
Batch ARCHIVE was run: 3 times...
Memory free for programs: 517 K
Time per run: 0:45:18
Total time elapsed: 2:15:55
Compression, sorted by: Speed
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
PKZIP 2.04g -a -es 458 000:25.2 885080 1.00
ARJ 2.39f a -m4 619 000:34.0 880381 1.35
PKZIP 2.04g -a -ef 668 000:36.7 816146 1.46
ARJ 2.39f a -m3 791 000:43.5 821257 1.73
PKZIP 2.04g -a -en 949 000:52.1 789620 2.07
ZIP 1.9 -1 1009 000:55.4 804893 2.20
ZIP 1.9 -3 1152 001: 3.3 791912 2.51
SQZ 1.08.3e a -q9 1285 001:10.6 811456 2.80
ZIP 1.9 -6 1328 001:13.0 787251 2.90
ARJ 2.39f a -m1 1340 001:13.6 791190 2.93
HYPER 2.5 -a 1375 001:15.5 854939 3.00
ARJ 2.39f a -jm1 1414 001:17.7 791088 3.09
LHA 2.52 a -n 1422 001:18.1 813064 3.10
PKZIP 2.04g -a -ex 1431 001:18.6 786214 3.12
SQZ 1.08.3e a -q6 1532 001:24.2 789518 3.34
ARJ 2.39f a -jm 1644 001:30.3 790977 3.59
ZIP 1.9 -9 1710 001:34.0 787657 3.73
SQZ 1.08.3e a -m1 1755 001:36.4 788795 3.83
SQZ 1.08.3e a -q3 1871 001:42.8 785959 4.08
SQZ 1.08.3e a -q0 2370 002:10.2 785811 5.17
HAP3 3.00 a 6384 005:50.8 790238 13.93
>> Again, we have a test set where HAP fails to get the absolute best
compression size, but this time, HAP is not quite so bad.
>> And again, SQZ takes significantly longer to get only a few bytes better
compression than PKZIP.
>> Again, ARJ lags behind ZIP and PKZIP in compression with decent speed.
>> And ARJ also lags behind ZIP and PKZIP when it comes to speed with
decent compression.
Compression, sorted by: Size
Program Description Ticks Min:Secs Size Relative
======== ====================== ====== ======== ======== ========
SQZ 1.08.3e a -q0 2370 002:10.2 785811 1.00
SQZ 1.08.3e a -q3 1871 001:42.8 785959 1.00
PKZIP 2.04g -a -ex 1431 001:18.6 786214 1.00
ZIP 1.9 -6 1328 001:13.0 787251 1.00
ZIP 1.9 -9 1710 001:34.0 787657 1.00
SQZ 1.08.3e a -m1 1755 001:36.4 788795 1.00
SQZ 1.08.3e a -q6 1532 001:24.2 789518 1.00
PKZIP 2.04g -a -en 949 000:52.1 789620 1.00
HAP3 3.00 a 6384 005:50.8 790238 1.01
ARJ 2.39f a -jm 1644 001:30.3 790977 1.01
ARJ 2.39f a -jm1 1414 001:17.7 791088 1.01
ARJ 2.39f a -m1 1340 001:13.6 791190 1.01
ZIP 1.9 -3 1152 001: 3.3 791912 1.01
ZIP 1.9 -1 1009 000:55.4 804893 1.02
SQZ 1.08.3e a -q9 1285 001:10.6 811456 1.03
LHA 2.52 a -n 1422 001:18.1 813064 1.03
PKZIP 2.04g -a -ef 668 000:36.7 816146 1.04
ARJ 2.39f a -m3 791 000:43.5 821257 1.05
HYPER 2.5 -a 1375 001:15.5 854939 1.09
ARJ 2.39f a -m4 619 000:34.0 880381 1.12
PKZIP 2.04g -a -es 458 000:25.2 885080 1.13
Extraction, sorted by: Speed
Program Description Ticks Min:Secs Relative
======== ====================== ====== ======== ========
PKUNZIP 2.04g -e (-ex) 179 000: 9.8 1.00
PKUNZIP 2.04g -e (-en) 223 000:12.3 1.24
PKUNZIP 2.04g -e (-es) 243 000:13.4 1.35
PKUNZIP 2.04g -e (-ef) 247 000:13.6 1.38
LHA 2.52 e -n 307 000:16.9 1.71
ARJ 2.39f e (-m1) 309 000:17.0 1.72
ARJ 2.39f e (-jm) 314 000:17.3 1.75
ARJ 2.39f e (-jm1) 318 000:17.5 1.77
ARJ 2.39f e (-m3) 337 000:18.5 1.88
SQZ 1.08.3e e (-q0) 393 000:21.6 2.19
ARJ 2.39f e (-m4) 409 000:22.5 2.28
SQZ 1.08.3e e (-m1) 414 000:22.7 2.30
SQZ 1.08.3e e (-q6) 432 000:23.7 2.41
SQZ 1.08.3e e (-q3) 435 000:23.9 2.42
SQZ 1.08.3e e (-q9) 442 000:24.3 2.46
UNZIP 5.00 -j (-6) 723 000:39.7 4.03
UNZIP 5.00 -j (-9) 727 000:39.9 4.05
UNZIP 5.00 -j (-3) 740 000:40.7 4.12
UNZIP 5.00 -j (-1) 754 000:41.4 4.20
HYPER 2.5 -x 996 000:54.7 5.55
PAH3 3.00 e 7935 007:16.0 44.17
>> And finally, PAH again takes a ridiculous 44 times longer than PKUNZIP
to extract.
╓──────────────────╖
║ Winners Set 12 ║
╓───────────────────╨──────────────────╨──────────────────╖
║ Category 1 (size) : PKZIP best, then ZIP, then SQZ ║
║ Category 2 (speed) : PKZIP best, then ZIP, then ARJ ║
║ Category 3 (abs size): SQZ best, then PKZIP, then ZIP ║
║ Category 4 (extract) : PKZIP best, then ARJ, then SQZ ║
╙─────────────────────────────────────────────────────────╜
Summary Stats...
----------------
The following summarizes the winners in each Category and the winners in
two combined categories. But first, let's repeat the description of each
Category:
Category 1: Great compression size, ok speed.
Look for an archiver that gets great compression size, but without
making you wait forever. Waiting a little longer for a significant
improvement is OK, but it is not OK to wait a lot longer for only
a few more bytes saved.
Category 2: Great compression speed, ok size.
Look for an archiver that is very fast without sacrificing a lot in
compression size.
Category 3: Absolute best compression size, speed doesn't matter.
Just look for the archiver that compresses the smallest and ignore
how long it took to do it, or how long it will take to extract.
Category 4: Great extraction speed, decent compression.
Look for an archiver that can extract fast, but only if its
compression was good enough to make de-compression meaningful.
Please note that categories 1 & 2 are a somewhat subjective. That is,
the winner depends somewhat on what I define as "ok speed" and "ok size".
Please feel free to pick your own "winners" from the raw data if you
don't trust my judgments.
Also, please remember that even if you ran the exact same tests on your
computer, you may NOT get the same results that I have gotten. This is
because a lot of factors can vary the results. These include:
o Amount of conventional memory.
o Amount of extended or expanded memory and what types (EMS, XMS, etc).
o Amount of secondary cache.
o Type of processor (286, 386, 486).
o Type of drivers loaded (disk cachers, ram disks, etc)
o Speed of hard disk.
o Use of floppy disk.
Of course, in real life, you won't even be compressing the same data as
I compressed for these 12 test sets. And, as these test sets have shown,
the archivers can vary greatly depending on the type of data compressed.
Thus, while this archiver comparison is generally accurate, it may not
be accurate for your circumstances. However, there is a solution if you
care to spend a little time. Just use my archiver comparer program (DCCMP)
to run tests on your own files and on your own computer. That way you can
decide for yourself what is the best archiver for you.
Now for the winners...
╓─────────────────────────────╖
║ Winners Category 1 (size) ║
╓─────────╨─────────────────────────────╨───────╖
║ Set 1: PKZIP best, then ZIP, then SQZ ║
║ Set 2: PKZIP best, then SQZ, then ZIP ║
║ Set 3: PKZIP best, then ARJ, then ZIP ║
║ Set 4: PKZIP best, then ARJ, then SQZ ║
║ Set 5: PKZIP best, then ZIP, then SQZ ║
║ Set 6: PKZIP best, then ZIP, then ARJ ║
║ Set 7: LHA best, then SQZ, then ARJ ║
║ Set 8: SQZ best, then LHA, then ARJ ║
║ Set 9: HAP best, then PKZIP, then ZIP ║
║ Set 10: HYPER best, then ARJ, then ZIP ║
║ Set 11: PKZIP best, then ZIP, then SQZ ║
║ Set 12: PKZIP best, then ZIP, then SQZ ║
║───────────────────────────────────────────────║
║ PKZIP: 8*3 + 1*2 + 0 = 27 ║
║ ZIP: 0*3 + 5*2 + 4 = 14 ║
║ SQZ: 1*3 + 2*2 + 5 = 12 ║
║ ARJ: 0*3 + 3*2 + 3 = 9 ║
║ LHA: 1*3 + 1*2 + 0 = 5 ║
║ HAP: 1*3 + 0*2 + 0 = 3 ║
║ HYPER: 1*3 + 0*2 + 0 = 3 ║
╙───────────────────────────────────────────────╜
╓─────────────────────────────╖
║ Winners Category 2 (speed) ║
╓─────────╨─────────────────────────────╨───────╖
║ Set 1: PKZIP best, then ARJ, then ZIP ║
║ Set 2: PKZIP best, then ZIP, then ARJ ║
║ Set 3: PKZIP best, then ARJ, then ZIP ║
║ Set 4: PKZIP best, then ARJ, then ZIP ║
║ Set 5: PKZIP best, then ARJ, then ZIP ║
║ Set 6: PKZIP best, then ARJ, then ZIP ║
║ Set 7: PKZIP best, then SQZ, then LHA ║
║ Set 8: PKZIP best, then SQZ, then LHA ║
║ Set 9: PKZIP best, then ARJ, then ZIP ║
║ Set 10: PKZIP best, then ZIP, then ARJ ║
║ Set 11: PKZIP best, then ZIP, then ARJ ║
║ Set 12: PKZIP best, then ZIP, then ARJ ║
║───────────────────────────────────────────────║
║ PKZIP: 12*3 + 0*2 + 0 = 36 ║
║ ARJ: 0*3 + 6*2 + 4 = 16 ║
║ ZIP: 0*3 + 4*2 + 6 = 14 ║
║ SQZ: 0*3 + 2*2 + 0 = 4 ║
║ LHA: 0*3 + 0*2 + 2 = 2 ║
║ HYPER: 0*3 + 0*2 + 0 = 0 ║
║ HAP: 0*3 + 0*2 + 0 = 0 ║
╙───────────────────────────────────────────────╜
╓────────────────────────────────╖
║ Winners Catagory 3 (abs size) ║
╓───────╨────────────────────────────────╨──────╖
║ Set 1: ZIP best, then PKZIP, then SQZ ║
║ Set 2: HAP best, then SQZ, then PKZIP ║
║ Set 3: HAP best, then PKZIP, then SQZ ║
║ Set 4: HAP best, then SQZ, then PKZIP ║
║ Set 5: HAP best, then SQZ, then ZIP ║
║ Set 6: HAP best, then SQZ, then ZIP ║
║ Set 7: HAP best, then SQZ, then LHA ║
║ Set 8: HAP best, then SQZ, then LHA ║
║ Set 9: HAP best, then SQZ, then ZIP ║
║ Set 10: HAP best, then HYPER, then ARJ ║
║ Set 11: SQZ best, then PKZIP, then ZIP ║
║ Set 12: SQZ best, then PKZIP, then ZIP ║
║───────────────────────────────────────────────║
║ HAP: 9*3 + 0*2 + 0 = 27 ║
║ SQZ: 2*3 + 7*2 + 2 = 22 ║
║ PKZIP: 0*3 + 4*2 + 2 = 10 ║
║ ZIP: 1*3 + 0*2 + 5 = 8 ║
║ HYPER: 0*3 + 1*2 + 0 = 2 ║
║ LHA: 0*3 + 0*2 + 2 = 2 ║
║ ARJ: 0*3 + 0*2 + 1 = 1 ║
╙───────────────────────────────────────────────╜
╓───────────────────────────────╖
║ Winners Catagory 4 (extract) ║
╓───────╨───────────────────────────────╨───────╖
║ Set 1: PKZIP best, then ARJ, then SQZ ║
║ Set 2: PKZIP best, then SQZ, then ARJ ║
║ Set 3: PKZIP best, then ARJ, then SQZ ║
║ Set 4: PKZIP best, then SQZ, then ARJ ║
║ Set 5: PKZIP best, then SQZ, then ARJ ║
║ Set 6: ZIP best, then PKZIP, then ARJ ║
║ Set 7: PKZIP best, then LHA, then SQZ ║
║ Set 8: PKZIP best, then LHA, then SQZ ║
║ Set 9: PKZIP best, then ARJ, then SQZ ║
║ Set 10: PKZIP best, then SQZ, then ARJ ║
║ Set 11: PKZIP best, then ARJ, then SQZ ║
║ Set 12: PKZIP best, then ARJ, then SQZ ║
║───────────────────────────────────────────────║
║ PKZIP: 11*3 + 1*2 + 0 = 35 ║
║ ARJ: 0*3 + 5*2 + 5 = 15 ║
║ SQZ: 0*3 + 4*2 + 7 = 15 ║
║ LHA: 0*3 + 2*2 + 0 = 4 ║
║ ZIP: 1*3 + 0*2 + 0 = 3 ║
║ HYPER: 0*3 + 0*2 + 0 = 0 ║
║ HAP: 0*3 + 0*2 + 0 = 0 ║
╙───────────────────────────────────────────────╜
╓──────────────────────────────────╖
║ Winners Catagory 1 & 2 Combined ║
╓──────╨──────────────────────────────────╨─────╖
║ PKZIP: 20*3 + 1*2 + 0 = 62 ║
║ ZIP: 0*3 + 9*2 + 10 = 28 ║
║ ARJ: 0*3 + 9*2 + 7 = 25 ║
║ SQZ: 1*3 + 4*2 + 5 = 16 ║
║ LHA: 1*3 + 1*2 + 2 = 7 ║
║ HAP: 1*3 + 0*2 + 0 = 3 ║
║ HYPER: 1*3 + 0*2 + 0 = 3 ║
╙───────────────────────────────────────────────╜
╓────────────────────────────────╖
║ Winners Catagory ALL Combined ║
╓───────╨────────────────────────────────╨──────╖
║ PKZIP: 31*3 + 6*2 + 2 =107 ║
║ SQZ: 3*3 + 15*2 + 14 = 53 ║
║ ARJ: 0*3 + 14*2 + 13 = 41 ║
║ ZIP: 1*3 + 11*2 + 14 = 39 ║
║ HAP: 10*3 + 0*2 + 0 = 30 ║
║ LHA: 1*3 + 3*2 + 4 = 13 ║
║ HYPER: 1*3 + 1*2 + 0 = 5 ║
╙───────────────────────────────────────────────╜
Conclusion...
-------------
Now I know that some people will just skip to this part of my
comparison and look at the above tables without reading the preceding
discussion. But if you do read the preceding discussion and look at
the raw data, you will see that the archivers can vary greatly depending
on the type of data being compressed.
Thus, one conclusion is the observation that what archiver is best
for you depends greatly on what types of data you work with and on how
you work with that data.
Moreover, the conclusion is really up to you, because only you can
decide how important the trade-off between speed of compression and size
of compression is.
If absolute size is your only criteria, then HAP is your archiver.
In the majority of test sets, it compressed the best. And in many of
those, it compressed significantly better. But this has to weighed
against its speed. Or rather, its lack of speed. HAP is up to 18 times
slower compressing and up to 50 times slower de-compressing!
If you compress large files, this speed trade-off can be really
important. After all, who wants to wait around for 12 minutes with one
archiver when another can do the job in less than 2 minutes.
And of course it gets more complicated when many of the archivers
offer multiple levels of compression size and speed.
And even if one archiver does a good job most of the time, at other
times it can preform terribly.
Nevertheless, when you go over all the data above like I have, certain
general things become apparent. And I think that the above summary tables
bare this out.
So, generally speaking...
-------------------------
PKZIP...
As the above tables show, PKZIP loses in only one Category, the
absolute size category. But even in this Category, it comes in a
decent third place with only HAP and SQZ beating it. But HAP has
a number of problems with it including poor support, poor features,
and terrible speed. And SQZ generally gets only a little better
compression while taking considerably longer to do so.
And consider this, while ARJ is generally considered PKZIP's main
competitor, in this Category where PKZIP comes in third, ARJ comes in
dead last (though very close to HYPER and LHA).
In every other Category though, PKZIP not only wins, but wins
with twice the score of anybody else. In test after test, PKZIP
generally was that quickest archiver to achieve a given level of
compression. And it not only compressed fast, but it also compressed
the best if you throw out the archivers that took excessively long.
PKZIP was not only the fastest archiver, it was also the most
consistent. Often, the other archivers would have cases where they
preformed very poorly in speed or size, but PKZIP remained reliable.
Not only is PKZIP reliable in speed and size of compression, but
because PKZIP is used by so many more people than any other archiver,
it is also a more reliable program. Even though PKZIP 2.04 came out
with a number of bugs, they were quickly found because of the massive
number of people using it, and then were quickly fixed.
Moreover, PKZIP is somewhat of a standard, and standards should
not lightly be thrown away (or quickly updated with new algorithms
I might add). Indeed, it is because of the PKZIP standard that
other compatible archivers like ZIP were created.
Add to this PKZIP's popularity, features, and availability of
compatible archivers on many platforms, and you have an easy winner.
ARJ...
It used to be that ARJ was strong on compression size and weak
on speed. Now just the opposite is true. ARJ did its best in the
two speed categories and did its worst in the two size categories.
ARJ came in second in the "speed" Category, but not by much. On
different machines, ZIP might have come in second place.
ARJ tied for second with SQZ in the "extract" category.
ARJ came in forth in the "size" Category, but perhaps ARJ could
do well enough on the specific types of data you use to move it up a
place or two.
Finally, ARJ came in dead last in the absolute size category.
Nevertheless, ARJ does have a LOT of features (if you're willing
to take the time to figure them out), and is based on portable code,
and so I would generally rate ARJ in second place overall, but with
ZIP and SQZ very close behind (if not better depending on your
preferences and circumstances).
ZIP...
I find it interesting that an archiver like ZIP performed as
well as it did. After all, ZIP is a freeware program that has
portable source code available that can be used freely. Moreover,
ZIP was written by a group of people that were often more concerned
with adding support for this or that platform then they were on speed.
If ZIP's extraction speed were improved to match the extraction
speed of SQZ or ARJ, then ZIP could be rated the second place winner.
Even as it is, ZIP could be rated in second place, seeing that it
did come in second place in the combined 1 & 2 categories.
In the end, ZIP's good placement strengthens PKZIP's 1st place
rating, and gives a good option for people who could use the source
code or simply like the price of freeware.
SQZ...
SQZ reminds me of ARJ a while back. SQZ does great in compression
size, but is lacking in speed. If the speed could be improved, then
SQZ would become the 2nd place finisher. If the speed were improved
a lot, it could conceivably become the 1st place winner.
Still, SQZ's size is not THAT much better than PKZIP, and thus,
it would be very hard for SQZ to replace such a solid standard.
HAP...
HAP is interesting because it sets a new threshold of compression.
I'm sure that some people will use it just because it can compress
significantly better than PKZIP. Even if it is so slow. And even
if the extraction is 50 times slower than PKUNZIP.
But watch out! HAP doesn't always compress well. In some cases
it compressed very poorly (and slow on top of that).
HAP seems to do well on ASCII files and especially well on English
text. It would be nice to see some archiver incorporate the HAP
algorithm as an option along with the other faster algorithms. And,
even if a person selects the HAP option, it should not be used on
files that it compresses poorly (like binary files).
LHA...
I had hoped that this newer version of LHA would do better. But,
for the most part, LHA is easily out done by PKZIP, ARJ, ZIP, or
SQZ, and so there's no reason to use it.
LHA preforms the best on large numbers of very small files.
HYPER...
Although HYPER can be put in last place for this comparison, it
shouldn't be completely written off. There are a few types of files,
(admittedly not many), where HYPER does better than any other
archiver. If you have these types of files, then HYPER could be
the archiver for you. Hard to imagine, but who knows?!
How do you find out? Just run my DCCMP program to test HYPER
against the other archivers on your own type of data.
Epilogue
--------
Well, I could have tested a lot more types of files, and I could
have tested them under a lot more conditions (like low memory). And, I
could have written a lot more about what all the results mean. But
this has already taken plenty of time. So, this will just have to
do...
Dean W. Cooper
June 9, 1993
